mysql [Warning] Invalid of old？ The solution to the table or database name problem

DROP TABLE IF EXISTS [TEMP_TABLE_NAME];
create temporary table [TEMP_TABLE_NAME] select col1,col2,... from [TABLE_NAME];
alter table [TEMP_TABLE_NAME] add unique idx_col1(col1);
After the above operation, the warning problem occurred several times. By querying and tracking debugging source code, there are the following clues and processing methods:
"[Warning] Invalid (old?) "[Warning] Invalid (old?) table or database name"

sql_table.cc:279
uint explain_filename (THD* thd, const char *from, char *to , uint to_length , enum_explain_filename_mode explain_mode )

The trace code found that the explain_filename function was only called in ha_innodb.cc: innobase_convert_identifier in innobase_convert_identifier in 1946.

 
/*****************************************************************//** 
Convert an SQL identifier to the MySQL system_charset_info (UTF-8) 
and quote it if needed. 
@return pointer to the end of buf */ 
static char* innobase_convert_identifier ( 
/*========================*/ 
char* buf, /*!< out: buffer for converted identifier */ 
ulint buflen, /*!< in: length of buf, in bytes */ 
const char * id, /*!< in: identifier to convert */ 
ulint idlen, /*!< in: length of id, in bytes */ 
void* thd, /*!< in: MySQL connection thread, or NULL */ 
ibool file_id) /*!< in: TRUE=id is a table or database name; 
FALSE=id is an UTF-8 string */ 

Looking up the clue, I found that the innobase_convert_identifier function was called in two places, and I continued the search with two clues.

Clues to 1:
ha_innodb.cc:2034
The innodb_convert_identifier function is called

 
/*****************************************************************//** 
Convert a table or index name to the MySQL system_charset_info (UTF-8) 
and quote it if needed. 
@return pointer to the end of buf */ 
extern "C" UNIV_INTERN char* innobase_convert_name ( 
/*==================*/ 
char* buf, /*!< out: buffer for converted identifier */ 
ulint buflen, /*!< in: length of buf, in bytes */ 
const char * id, /*!< in: identifier to convert */ 
ulint idlen, /*!< in: length of id, in bytes */ 
void* thd, /*!< in: MySQL connection thread, or NULL */ 
ibool table_id) /*!< in: TRUE=id is a table or database name; 
FALSE=id is an index name */ 

From the point of view of function definition and function function, this function converts the table name or index name of mysql to utf8, which is related to character set. Looking at the existing database character set and the generated temporary table character set are lanti1, inference is a possible reason for 1.
Treatment method:
Change the character set of the database to utf8 and see if the error still occurs in the database.

Clues to 2:

 
ha_innodb.cc:6269 
 call innodb_convert_identifier function  
/*****************************************************************//** 
Creates a table definition to an InnoDB database. */ 
static create_table_def ( 
/*=============*/ 
trx_t* trx, /*!< in: InnoDB transaction handle */ 
TABLE* form, /*!< in: information on table 
columns and indexes */ 
const char * table_name, /*!< in: table name */ 
const char * path_of_temp_table, /*!< in: if this is a table explicitly 
created by the user with the 
TEMPORARY keyword, then this 
parameter is the dir path where the 
table should be placed if we create 
an .ibd file for it (no .ibd extension 
in the path, though); otherwise this 
is NULL */ 
ulint flags) /*!< in: table flags */ 

In the create_table_def function, after calling row_create_table_mysql function, when the return value is DB_DUPLICATE_KEY, innodb_convert_identifier is called, thus triggering the warning.

 
row0mysql.c:1820 
UNIV_INTERN int row_create_table_for_mysql( 
/*=======================*/ 
dict_table_t* table, /*!< in, own: table definition 
(will be freed) */ 
trx_t* trx) /*!< in: transaction handle */ 

A deeper function is called in this function, but from the debugging code, the point that caused the problem is not found at the moment.
Treatment method:
In cases where the processing in clue 1 does not resolve the problem, proceed to the code analysis in step 1.
Conclusion:
After the above code debugging and analysis, two clues, but 1 straight failed to reproduce the problem. Therefore, only lead 1 can be processed on the existing server at present. If the problem still occurs after processing according to clue 1, step 2 will be analyzed in depth.

The author king_wangheng